A multiversion database is one which can be queried (i.e., asked or interrogated) as to what the state of the database was at a specified time. In such multiversion databases, also called temporal databases, all updated data is "stamped" with a time value, usually with a time value corresponding to the time at which the data was updated. With the appropriate support (i.e., software), a query of the timestamped database can provide a transaction consistent view of the database as it existed at a specified time. Such temporal queries can be of use in financial applications, medical record systems, engineering design, and so on.
The present invention focuses on transaction time. All updates made by a transaction to a database are stamped with the same time. The timestamp is stored as an attribute of the data. The timestamps of transactions must be ordered correctly so that the order of the timestamps represents a correct serialization of the transactions.
Transaction time can also be used to organize data. The idea is that data that is no longer current can be stored separately from current data. The "historical" data is never updated, and hence can be stored on "write-once, read many" (WORM) optical disks. Data that is current may continue to be updated, and is therefore stored on magnetic disks and in random access memory so that the current data can be readily modified. However, as will be appreciated by those skilled in the art, all timestamped data could be stored on magnetic disk or it could all be kept on a WORM disk.
Timestamping data with the time of the transaction that entered it is not a new idea, and many articles on this subject appear in the computer science literature. Timestamps have been suggested as a way of performing concurrency control. Most of the efforts at using timestamps in this way, however, have not turned up in system implementations.
What the present invention provides, that has not be provided in the prior art, is a method of consistently timestamping data in a distributed database without unduly hurting the system's performance, and also providing a "delay lock" mechanism which facilitates the processing of multiple transactions which partially overlap in time while compromising neither the reliability of the data being used nor the consistency of the timestamps on the data.